home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga Format CD 41
/
Amiga Format CD41 (1999-06)(Future Publishing)(GB)[!][issue 1999-07].iso
/
-seriously_amiga-
/
misc
/
mmulib
/
readme
< prev
next >
Wrap
Text File
|
1999-04-19
|
21KB
|
537 lines
The mmu.library project © 1998,99 the mmu.library development group, THOR
-----------------------------------------------------------------------------
Release 0.26
------------
- Fixed a bug in the exception handling, forgot to restore a6.
- Fixed the return value of RebuildTree(). It's now TRUE on
success, not DOSTRUE.
- Fixed a bug in the table builder, merged sub-tree were released
incorrectly.
- Added the WithoutMMU() LVO entry.
- Removed the AllocLineMem() LVO, this one was useless.
Release 0.25
------------
- Debugged 060 exception handler again. Found only one bug, ROM
emulation was broken.
- Enhanced AbsExecBase accesses - does no longer block interrupts
unnecessary.
- Fixed parts of the exception handler to read the faulty instruction
from the correct function code space.
- Added a complicated test for the EC030 processor that should
finally work.
- Enabled the MMULib internal exception handler test.
- Removed all accesses to the ppc.library and reserved entries.
PPC.lib compatibility is no longer an issue for me. The MMU.lib
is WarpOs-compatible, though, as long as the system isn't
infected by Ralph's "software".
- Added a safety test in the MMUCacheTest program to avoid
hangs.
Release 0.24
------------
- Fixed the 030/851 exception handler, especially the emulation
of instruction access of a possibly invalidated zero page,
now really, *BIG* thanks to Dave!
- MuForce does no longer ignore a remapped ROM. (Oops!)
- MuForce does no longer touch the mapping of the fspace
unless told to do so.
- Fixed the assembler includes and autodocs, thanks to Tilman!
- The context management of the library does no longer
reset the remap destination in case the memory remap flag
is not included in the mask settings. (Oops!)
- Fixed the MMU table builder for MMU tables using more than
32K entries.
- The startup code selects now a better page layout for 030/851
processors.
- MuForce tries now to re-use an already relocated vector base
if possible.
- Tiny speedup in the "InstallDescriptor" routine could speed up
MMU table building. There's room for more speedups, though.
- Added a "nommu" flag for the MMUCacheTest program to check
your HD without the mmu.library. If this flag is used, the
program *MUST* be run without the mmu.library currently loaded.
Related fixes of COP (release 1.73, not included in this distribution):
- Fixed emulation of instruction access to the zero-page.
- Fixed the RestoreVBR option.
- Fixed the MMU disable mechanism on startup.
Special thanks goes to Dave "Ragman" for finding a lot of bugs in the 0.21
release.
-----------------------------------------------------------------------------
Tests to be done for the 0.25:
- Please copy the "MMUCacheTest" program to your HD, then reset the
computer, hold both buttons and disable the startup-sequence from the
boot menu. (The MMUCacheTest program has been fixed, there's a chance that
tests run better with the 0.25!)
On the boot shell, enter
"SetPatch"
to install the system specific patches, *DO NOT* start any other program.
Please run now
MMUCacheTest DH0: nommu
^^^
insert the name of your HD here, should be tried with other
devices as well.
Please let me know how this goes; especially, I'm interested in the last
line of output from the program:
Task switching was disabled 0 times, run 122659 RAM accesses.
^^^^^^^^
This number shouldn't differ from zero.
Second test would be to run just the same program again, but without
the "nommu" keyword.
Except that, as usual, just try the software: MuForce, MuFastRom and
all the other stuff.
-----------------------------------------------------------------------------
Compatibility warnings and bad software:
- The MMU tables generated by the "CPU FastROM" command, an official CBM tool,
are simply wrong if run on a 030 processor. Chip memory is marked as
"cacheable", which is plain wrong. Already spoke to Michael Sinz who agrees
in that point. Don't use it, run "MuFastRom" instead.
- The MMU tables build by "SetCPU FastRom" are not very well suited for
MuForce. The MMU library will replace the table layout by something more
adapted.
Since these programs may install a "bogus" exception vector, you shouldn't
run both programs with the "FastROM" option. If you absolutely want to do,
run them *before* installing any MMU.lib related program and COP - remember,
you have been warned. "MuFastROM" will do better once the library is finished.
- CMQ060.lha from the Aminet: This program uses the MOVE16 instruction to
"speed up" the copy mem routines of the Os. Besides that the speedup is
minimal, you should be informed that this instruction is not fully
supported by the Amiga hardware. A MOVE16 into the chip memory could yield
to "strange and wonderful things", and may or may not work. Its burst
accesses simply don't fit into the DMA access mechanism of the Amiga
custom chips. (Note that no other instruction will try burst accesses
into non-cacheable memory!)
Moreover, if a MOVE16 crashes, the mmu.library is out of buisiness, it will
simply guru. Do not run this program!
MOVE16 is one of the non-supported instructions in an Amiga system, others
are TAS, CAS and CAS2 (which are of little use in a single processor system).
For more detailed information of MOVE16, check either the enforcer.guide or
the motorola documentation, I'm not making this up, and this is not
mmu.library related.
Known Bugs:
-----------
The MMU table manager rebuilds currently the MMU tables for a
complete memory block even if only a minor sub-block was changed.
Therefore, it may take longer to build the MMU table than absolutely
required. I decided not to change this behaiviour because it
keeps the mmu tables clean and optimized and avoids fragmentation.
The MMU library builds currently 68030 MMU tables with the
REPAIRABLE flag set less efficient than it could. However, it
was felt that a consistent table layout is more helpful than the
(minimal) speedup.
The library does not yet provide a mechanism to adjust the page
size, even though it is flexible enough to adapt to any page size
possible. This feature will be added in the form of tags to the
CreateContext() call.
The library does not yet contain a workaround for a 040 firmware
bug: If an illegal, line A, chk or unimplemented floating point
instruction is located at the last 16 bits of a page and the next
page is not available, the 040 generates an access fault instead
of the proper exception. The fault address is the address of the
missing page, and the PC points to the instruction in the preceeding
page. This doesn't matter too much currently, it might become
relevant in a VM system.
Somehow the library seems to cause hangs of DMA/PIO devices. I
can't comment on that currently since I haven't had a chance to
test that myself. I can't comment on that, I've no idea...
Might happen that the library causes somehow hangups of my 040
system. Possibly because of a 040 MMU firmware bug, possibly
because of interactions with my debugger COP, possibly because
I'm using an old release of the 68040.library. This has to be
checked out, still - haven't had a hang for weeks now....
These bugs will be fixed within the next releases of the library, including
all the other bugs you may find.
-----------------------------------------------------------------------------
Special thanks goes to:
-Ralph Babel for giving information about the CachePreDMA/CachePostDMA
functions and for some internals allowing me to write the MuOmniSCSIPatch.
-Carsten Schlote for starting development of a mmu.library aware 68060.lib.
-Michael Sinz (a real BIG thank you!) for discussing a lot of details of
CachePreDMA/CachePostDMA, for sending me the sources of these functions
in his 68040, and especially - and that's really great - for making the
Enforcer sources available and for allowing me to reuse the exception
handler of the Enforcer. This will happen in one of the next releases.
-Bjoern Schmidt for allowing me to run some tests on his 060 and for
keeping several afternoons free for me.
-All the testers for running tests and sending me detailed information about
their systems.
Thank you to all of you, this project won't clearly possible without your
support!
-----------------------------------------------------------------------------
What is this:
-------------
The mmu.library provides functions for MMU related operations
as write- or read-protecting certain areas of memory for a
given set of tasks, or marking memory regions as "swapped"
virtual memory support. It offers an abstraction level on top
of the actual MMU and a unified interface for MMU purposes.
The MMU lib does NOT implement virtual memory, that's the purpose
of another library - the memory.library. There's no much reason why
any application except the memory.library and probably some debugging
tools should call this library directly. The memory.library functions
on top of this library should suffer for "all day purposes".
The goal of the mmu.library is to provide an "abstraction layer" on
top of the hardware, to allow programs to make use of the memory
management hardware of the more advanced members of the MC68K
processor family. Programs using the functions of the mmu.library
do not need to modify the MMU tables directly and hence will not
conflict with each other. The mmu.library interface provides all
necessary functions to do that. This will allow programs like
Enforcer and VMM to cooperate nicely with each other, provided both
use this library.
Since writing the mmu.library is a tough job, I need your help!
Currently, only two systems are available right here, a MC68030 40Mhz
ad a MC68040 33Mhz. While this is better than before, I still need your
help since the library is supposed to support all members of the MC68K
family (the 68851, 68040 and 68060 MMUs).
Since I don't have all these systems available, I need your
help - writing system software without being able to debug is "a bit"
tricky.
What can I do as a non-developer:
---------------------------------
Testing! Check the documentation of the programs within the documentation,
especially what you find the "MuTools" drawer, and lemme know how it goes.
Please run the MMUCacheTest program, too. It takes one argument, the
name of a hard disk. Don't worry, it won't harm your HD, it will simply
read sectors from it to test some critical MMU.library functions.
Please perform this test with as many "disk-like" devices as you can, i.e.
hard disks, CD Roms, SCSI and IDE devices of various kinds.
Here's an example run:
1.SYS:> MMUCacheTest DH0: <RETURN>
MMUCacheTest 0.20 (6.2.99) © THOR.
Internal use only, no commercial use.
Initial read, calculate checksum.
Running the initial device test.
This test checks whether the connected device works reliable.
It does NOT check the MMU code which is not needed for this
initial run.
This test SHOULD NOT fail. In case it does, your device or
host adapter is broken, but not the MMU logic.
The initial test passed.
Running the real test. If this test fails, something is wrong
with the CachePreDMA/CachePostDMA logic. In this case, please
sent me an EMail so I can fix it.
The MMU cache test passed. Run 165329 RAM accesses.
In case any of the tests fail, or you see crashes, please let me know.
THIS IS AN IMPORTANT TEST. If anything fails here, the future mmu.library
might trash disk input.
If the tests pass, check the number of RAM accesses shown in the last line
of the output. This number *should* be larger than zero. If it's not, then
the test did effectively nothing. Please let me know in this case either,
I'll try to invent a more effective test in this case.
A third - non-MMU related - test is the SCSIDMATest program, please run
this test as well.
It works like this:
1) Run the SCSIDMATest program. It will print a message and wait for ^C.
DO NOT YET abort the program.
2) Play with your harddisk, read files, write files, whatever you like.
3) Stop the program and please collect the output, and please send it to my
email address at thor@math.tu-berlin.de.
Here's the output for my system:
CachePreDMA/PostDMA patches installed. Please start massive
disk activity now, keep the program running for several minutes.
Then remove it with ^C.
The patches have been removed.
The DMA activity counter is 0. CachePreDMA called 0 times,
0 times without DMA_Continue, CachePostDMA called 0 times.
The DMA activity counter is of special interest. It should be zero, or at
least a *small* number. If it's not, please lemme know the name of the
device your HD is controlled by, i.e. "gvpscsi.device", "oktagon.device",
"scsi.device", "cybscsi.device" etc... Would be nice if you could provide a
version information as well, i.e. enter a line like
version gvpscsi.device
on the shell and lemme know about the output.
What can I do as developer:
---------------------------
I'm still willing to give away the sources of the library, provided that
a) you keep them private and don't give them away (really!)
b) you help me debugging the library by using them.
They are no longer included in the "standard" distribution because that
would enlarge the archive unnecessary for most testers. In case you're
interested, just sent me a note.
What about joining the mmu.library development group? This is just a couple
of people contributing to this library by writing code and exchanging their
wisdom by EMail. It's a non-profit organization that works on the development
of this library. If, whenever, this library becomes a commercial product,
you'll get paid, of course. However, the current library, as it is, is planned
to be freeware, so don't expect money. It doesn't look like there's currently
a market for this library project, unfortunately.
Contact me at thor@math.tu-berlin.de if you want to join this group.
What can be done just now is to run this library on your machine and find
and correct bugs. As I said, I haven't tested the 68851 and the 68060
parts at all.
You might also want to develop software for the library. You find the
required includes and autodocs within this archive, as well as example
sources. In case you need support, just contact me.
There are a lot of library functions that require a bit more testing:
- All the functions that bypass the abstraction layer:
GetPageProperties(),SetPageProperties(),PhysicalPageLocation()
- Remapping of memory and adding this memory to the exec memory pool.
- Building private contexts and swaps of the MMU tables on task swaps.
- SWITCH and LAUNCH type exception handlers.
I haven't been able yet to run all required tests, sorry.
What is in this distribution:
-----------------------------
Autodocs:
The preliminary version of the autodocs of the mmu.library and
the memory library, as well as a file describing some planned
implementation details.
Include:
The includes for a C compiler as well as the ".fd" file for the
library functions written so far.
C_Sources:
C sources of sample programs. All programs that are distributed
under the THOR-Software licence are published here. The
sources of MuForce *are not* available because they are partially
copyrighted by Michael Sinz.
MuTools:
Contains a small collection of programs that make use of the MMU.
For details, check their guides in this drawer.
Shell_Only:
A couple of programs that can be run from the shell only, as there
are:
MMUCacheTest:
Reads from HD, partially non-cache aligned to check whether
boundary pages of the DMA buffer are correctly marked as non-
cacheable. See above for how the test looks like.
SCSIDMATest:
Checks whether the hard disk driver uses CachePreDMA/CachePostDMA
consistently. See above for the test. The source is included.
TestMMU:
This program is purely for debugging purposes. If you run it,
you won't see any specific action. It simply opens the library
manually and executes the library init function in the task
context of the calling program. Hence, this program can be used
to step thru the lib-init function with a standard debugger
without the need to catch "ramlib".
If you still discover bugs and want to try, then load this
program into a debugger of your choice, and step thru it. library.
Known bugs and problems of this implementation:
-----------------------------------------------
Things that require testing:
- TTx register parsing updated. Should work fine with all the
printouts I've collected, but you may still want to test it.
- 68851, and 68060 code likely untested, but I'm getting better.
I NEED YOUR HELP!
- GetPageProperties/SetPageProperties.
- Adding remapped memory to the exec free list.
Things not yet implemented:
- Patches for ppc libraries due to missing support. Grrr.
- Functions to setup a different page size.
Things the current design does not allow:
- The MAPP_USED and MAPP_MODIFIED flags are not kept consistent
by the library except for MAPP_SINGLE pages. I consider this
as a minor problem since single page mode is required for
virtual memory anyways.
- MMU tables using the function codes. The amiga design shouldn't
allow this anyways, but I don't know whether there's a board
that makes use of them. (Doesn't look like, though).
- Boards with two different MMU's on board. I've heard some
rumours that there are actually 68040 boards with an additional
68851. The current library assumes a 68040 MMU.
- The current implementation does not yet check completely whether
an "EC" type processor (without an MMU) is on-board. This check
should work for the 68060 since there's a hardware register for
it, and there's now even a test for a EC040 which hopefully
works, but there's NO test for the EC030 because I wasn't able
to find a simple one. The library contains currently a
complicated one which is still "commented out" because it
requires the full exception handler which hasn't been tested
too much.
- The current design allows only one global supervisor table since
I thought a task specific supervisor table might not make too
much sense anyways.
I would really enjoy if someone (Ralph Schmidt?) could give me some internal
information about the P5 boards and their MMU usage. I'm now well informed
about the internals of the "real" 68040 and 68060 libraries (and not of the
P5 wierdos of this library), great thanks to Ralph Babel and Michael Sinz.
However, I'm still looking for information about the ppc.library. I got the
autodocs, but this is unfortunately not sufficient. The following questions
remain:
- Does the ppc.library route all MMU table accesses thru PPCAllocMem(),
or do I have to patch all entries?
- Is there an entry in the P5 68060 library to change the MMU table?
- Is it enough to adapt the cache modes of the PPC allocated memory manually,
or does the ppc.library more dirty tricks?
Any kind of information will be appreciated!
Debugging:
----------
Yes, that's a problem of its own. Obviously, the MMU library uses some
"heavy magic" supervisor code which is not available for a standard monitor.
Even though the DevPac "MonAm" is a nice and powerful debugger, it's not
powerful enough for these tricks. There's currently - up to my knowledge -
only one debugger that can do this for you, and that's my own... (-;
Check the Aminet and my web-page for COP, then read the documentation. If,
after reading, you STILL want to use it, you're the right guy for this
job... (-;
COP might be setup to load the symbols of the library, to help you a bit.
The current version of COP is 1.73. Try to get the latest, if possible.
Recommended reading:
--------------------
The following books are recommended reading:
Motorola 68030 Enhanced 32-bit Microprocessor User's Manual
MC68030UM/AD Rev.3
Motorola 68040 User's Manual
M68040UM/AD Rev.1
Motorola 68060 User's Manual
M68060UM/AD Rev.1
Motorola M68000 Family Programmer's Reference Manual
M68000PM/AD Rev.1
Amiga Hardware Reference Manual, 3rd ed.
Addison-Wesley Publishing Company, Inc.
ISBN 0-201-56776-8
Amiga ROM Kernal Reference Manual, 3rd ed., Volume "Libraries"
Addison-Wesley Publising Company, Inc.
ISBN 0-201-56774-1
The Amiga Guru Book, 2nd Ed.
Ralph Babel, Taunusstein 1989,1993
Additional sources:
The Amiga Developer CD V1.1
(newer versions are already available, but 1.1 is good enough).
The Enforcer.guide.
Michael Sinz's documentation in the AmigaMail, on the DevCD 1.1.
Final words:
------------
The mmu.library and the memory library will be my last project for the Amiga.
It depends a bit on what happens with the Amiga in the next two years whether
a PPC version of this library is required or not; hence, after all, this
can't be much more than a toy project that came several years too late.
However, as it looks now, Amiga goes PC. I'm currently not willing to
support this step and the Intel/Microsoft illnesses.
\begin{sarcastic}
While Commodore just dug the grave for the Amiga, Gateway is turning it into
a zombie.
\end{sarcastic}
So long,
Thomas